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DIGITAL RIGHTS MANAGEMENT SYSTEM FOR MULTIME DTA MESSAGES 

PROTECTION AND TRACKING 

FIELD OF THE INVENTION 

The present invention relates to content protection for multimedia content. 

BACKGROUND OF THE INVENTION 

Background technologies relevant to understanding the present invention include: 

- Simple Object Access Protocol (SOAP), which is described on the World Wide 
Web at: www.w3.org/2000/xp/Group/ 

- SOAP Security Extensions: Digital Signature (SOAP DSIG), which is described 
on the World Wide Web at: www.w3.org/TR/SOAP-dsig/ 

The disclosures of all references mentioned above and throughout the 
present specification (including, without limitation, references mentioned in Appendix 
A), as well as the disclosures of all references mentioned in those references, are hereby 
incorporated herein by reference. 
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SUMMARY OF THE INVENTION 

The present invention, in preferred embodiments thereof, provides a system and method 
for content protection for multimedia content distributed in a mobile network by 
Multimedia Message Service Center (MMSC). In preferred embodiments, the system 
includes a Digital Rights Management (DRM) server connected to the MMSC by a 
dedicated DRM protocol and/or by connection via selected MMSC protocols, adapted 
and modified for DRM information transfer. The system may also include a DRM User 
Agent (UA) on mobile handsets. 
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BRIEF DESCRIPTION OF THE DRAWINGS AND APPENDIX 

The present invention will be understood and appreciated more fully from the 
following detailed description, taken in conjunction with the drawings in which: 

Fig. 1 is a simplified block diagram illustration of a 3GPP MMSC System having 
an MM9 interface; 

Fig. 2 is a simplified block diagram illustration of a Multimedia Message Service 
Center (MMSC) including a Digital Rights Management (DRM) server and 
communicating through a DRM protocol which can be implemented as a stand-alone 
protocol and/or a combination of modifications of existing MM protocols (e.g. MM7, 
MM1), constructed and operative in accordance with a preferred embodiment of the 
present invention; and 

Fig. 3 is a simplified block diagram illustration of a Multimedia Message Service 
Center (MMSC) including a Digital Rights Management (DRM) server, constructed and 
operative in accordance with another preferred embodiment of the present invention. 

The following appendices will aid in understanding the detailed description: 
Appendix A, which is a particularly detailed description of one preferred 

implementation of an interface between a service provider and a DRM Server; and 

Appendix B, which is a general representation of major use cases, outlining one 

preferred implementation of an interface between DRM server and MMSC. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

Reference is now made to Fig. 1, which is a 3GPP MMSC System diagram with an 
additional MM9 interface. Fig. 1 is based on the standard MMSC architecture as it is 
defined by 3GPP in reference [1] (a copy of which may be found on the World Wide 
Web at: webapp.etsi.org/action%5CPU/20040120/ts__123140v050900p.pdf) with the 
addition of a transcoder node connected by MM9 protocol. 

It is appreciated that MM9 is not fully standardized yet and its implementation may differ 
and may have proprietary extensions and modifications for each MMSC and transcoder 
vendor. 

The DRM System for Multimedia Message (MM) protection preferably comprises, at the 
server side, one of the following: 

A DRM component, integrated within the MMSC through a dedicated protocol, 
similar to the current approach to MMSC - transcoder interconnection, as shown in Fig. 
2. The dedicated protocol could be very similar to that described in Appendix A and 
illustrated in use cases in Appendix B, with additional support for extended business 
models if desired. (It is appreciated that Appendix A comprises a particularly detailed 
description of one preferred implementation of an interface between a service provider 
and a DRM Server and Appendix B comprises a general representation of major use 
cases outlining one preferred implementation of an interface between DRM server and 
MMSC; the examples of Appendix A and Appendix B are not meant to be limiting). 

H) Stand-alone server(s) acting like a network probe and/or proxy, as shown in 

Fig. 3. 

The system of Fig. 3 preferably protects / tracks content following the steps below. The 
DRM Server preferably: 

1 . Listens to MM7 protocol analyzing MM7 submit. REQ messages. 

2. For each message, extracts from the message Value Added Service Provider 
(VASP) ID and Value Added Service (VAS) ID and compares them with a pre- 
defined list of the content vendors IDs that request content protection/tracking. If 
the content protection/tracking was required, then: 

3. Generates hash data which uniquely identifies MM content and stores this data in 
the DRM DB together with other data about the message, such as, for example 
VASP & VAS IDs, message recipient(s) address(es)/distribution list(s), 
submission timestamp, subject, service code, message class, message distribution 
indicator and other appropriate parameters. Data hash technology is well-known 
in the art; any appropriate data hash technology may be used. 

4. Optionally, analyzes content and replaces it by the same content with a 
watermark. This could be used with or instead the content hashing as described in 
step 3 immediately above 

4 
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5. Analyzes every message transferred via proprietary MMSC-transcoder protocol 
(MM9). For messages, passed from MMSC to the transcoder, the DRM Server 
generates content hash and/or looks for content watermark. The generated hash is 
compared with the stored hashes (or the found watermark compared with DB 
stored watermarks). If the same hash/watermark is found in the DRM DB, the 
incoming (to transcoder) message is marked as "to be protected/tracked" by 
storing incoming message parameters such as transaction ID, message ID or 
similar. Persons skilled in the art will appreciate that specific implementation 
details depend on the MMSC-transcoder protocol details, which differs for 
various vendors. 

6. Verifies the same parameters (transaction ID, message ID or similar) for any 
outgoing (from transcoder) message while listening to MM9 protocol. If the 
message should be protected, the DRM Server encrypts content, fully or partially. 
Every attachment can be protected individually by using different algorithms 
and/or keys or all the attachments can be encrypted together with the single key. 
Any appropriate encryption algorithms and key management and key delivery 
mechanisms may be used. 

7. Generates an additional post-transcoding hash data for the transcoded content and 
stores this data in the DRM DB. 

Then the message is delivered by MMSC, preferably using standard methods known 
in the art, to the recipient MMS UA. 

In order to implement the protection for the super distribution (i.e., forwarding all the 
content items received within the MM or selected content items only from one mobile 
subscriber to the another one) in case of Multimedia Message (MM) submitting (which 
may occur when only selected attachments of received MM are forwarded) and MM 
forwarding (entire MM), the DRM server preferably: 

1 . Listens to MM1 protocol and analyzes every MMljsubmit. REQ message by 
generating a content hash. The hash is compared to the "post-transcoding" hashes 
in the DRM DB. If the generated hash matches a hash in the DB: 

2. Registers message parameters such as originator, recipients list, timestamp and 
others as appropriate. 

3. Verifies the rights of the recipient(s) to receive the message. If the recipient(s) is 
not allowed to receive the message, e.g. the MM was requested to be forward- 
locked by the content or service provider, the DRM Server may: 

a. Silently ignore the MM forward attempt. 

b. Inform the MM originator that the delivery is not allowed, by SMS, MMS, 
WAP push or other allowed methods. 

c. Inform MM recipient that there was a MM forwarding attempt. 

If the message delivery to the recipient(s) is allowed, optionally the DRM Sever 
may request the recipient to purchase the appropriated rights for the forwarded 
content first and execute all the steps below only when the purchase confirmation 
will be received. If the DRM Server is allowed to deliver the message: 

4. Decrypts content and replace the encrypted attachments by clear content inside 
the MMljsubmitREQ message. Then the message is delivered to the MMSC 
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Server/Relay which in turn may pass it to the transcoder. Further operations are 
defined in steps (5)-(7) for MM9 above. 

5. In addition, listens to MM1 protocol and analyzes every MMlj-etrieve.REQ and 
MMl_retrieve.REQ messages, extracting message reference, typically in the form 
of a Universal Resource Identifier (URI), which URIs are well-known in the art, 
from MMljretrieve. REQ and storing the message reference in the DRM DB if 
content hash generated by the DRM Server for content passed in 

MM1 _retrieve. RES matches with a hash stored in the DRM DB. 

6. Listens to MM1 Jorward.REQ, extracting message URI and comparing with the 
stored URIs. For the matching URIs, registers in the DRM DB the recipient's 
address and originator address presented in MM1 Jbrward.REQ message. 

Additionally, persons skilled in the art will appreciate that the DRM server preferably, in 
both cases (I and II), provides portal functionality for the DRM UA to supply keys as 
necessary, both on DRM UA request or provided by DRM Server by an appropriate push 
method such as SMS, WAP push or MMS. 

At the handset side the DRM User Agent (UA) implementation can be one of the 
following: 

1) No DRM UA 

In this case the DRM Server alone preferably supports the following business 
models: content tracking, network forward lock (with/without notification of the 
originator), controlled super distribution. 

2) DRM UA built-in the MMS UA. 

3) DRM UA acting as a stand-alone application / group of applications (such as, 
for example, a Symbian recognizer [which is well-known in the art and 
described on the World Wide Web at: 

www.symbian.com/developer/techlib/v70sdocs/doc_source/devguides/cpp/ap 
plicationframework/recognizersoverview.guide.html ] + UA) or as a part of a 
third-party stand-alone application (DRM UA for a player or browser), when 
the application is associated with the protected content types (and called by 
the Operating System (OS) when a MMS with protected content is received) 

4) DRM UA acting as a part of the native phone software (OS, drivers etc) 
(including any HW implementation) - in the most common case is the same as 
(1); other options: part of a web/WAP browser. 

For cases (2)-(4) DRM Server and DRM UA will support any appropriate 
business model implemented in the given DRM System, e.g., pay-per-count, pay- 
per-time, rental or permanent purchase. 

In certain preferred embodiments of the present invention, comparing of a hash to 
"post-transcoding" hashes stored in the DRM DB, as described above, may aid in 
providing optimally transcoded content to a recipient. When a super distribution 
request is received, including content which the requester wishes to distribute, the 
content is identified by comparing a hash of the content to stored "post-transcoding" 
hashes in the DRM DB. The DRM DB preferably also stores the original "pre- 
transcoded" content, associated with one or more of the "post-transcoding" hashes. 
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Persons skilled in the art will appreciate that the original content can thus be easily 
identified. The original content can then be optimally transcoded for the new 
recipient. 

In certain preferred embodiments of the present invention, DRM is applied in the 
DRM Server on a "best effort" basis, as described below. 

There are different types of content protection that a DRM-enabled device can apply. 
There are some devices that have only one type (typically a simple type, such as 
OMA DRM vl forward lock) of content protection. Other, more sophisticated or 
newer devices implement multiple DRM methods, such as OMA DRM vl forward 
lock, OMA DRM vl combined delivery, and OMA DRM vl separate delivery, all of 
which are well-known in the art. There are (or are soon expected to be) some 
commercially available devices that implement the OMA DRM v2 standard, which is 
backward compatible and therefore includes all the methods of OMA1 . In addition or 
instead, a mobile device can have any proprietary DRM solution installed. For 
instance, SonyEricsson has implemented some devices with their own proprietary 
forward-lock method for content protection. 

In this situation of multiple DRM choices available at a single device it is uncertain 
which content protection method the DRM Server should pick up for a specific 
mobile device if a service or content provider did not specify explicitly what type of 
content protection they want to apply. In such a case, where not specific type of 
content protection has been requested, the inventors of the present invention believe 
that "best effort", as described herein, is preferred. 

In "best effort", the DRM Server preparing content to a certain mobile device or a 
group of similar models will always use the protection method allowing the highest 
security level for the given model or a group of models. To achieve this result, the 
DRM Server consults UAProf (User Agent Profile) data, published by the device 
manufacturer, which includes the DRM capabilities of the device; alternatively the 
DRM Server uses its own knowledge of the DRM methods the device can apply. 
Since the DRM Server can be integrated within a content delivery service, the content 
delivery service can provide the Server with the knowledge of whether the mobile 
device has any DRM Agent installed and of what type. For example, if a user 
downloaded an DRM-enabled player from a content portal, the portal can inform 
DRM Server which user has received which DRM agent. Alternatively, if content 
protection procedures have been initiated by the user with involvement of the DRM 
Agent, the agent software may report its version to the DRM Server, thus providing 
the DRM Server with the information about available DRM version. 

The DRM Server DB is also preferably continuously or periodically updated with 
information about new phone models and their DRM abilities, thus allowing the 
DRM Server to use the strongest protection afforded by a new device when the new 
device arrives to the market. 
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Preferably, the "best-effort" protection technique means that in case that the requested 
DRM protection method is unavailable for the given handset type, the DRM Server 
will try to use the most secure DRM protection method available for the given 
handset according to the best DRM Server knowledge for the requested content, also 
taking in account the content's MIME type. For instance, if a service provider asks 
for the "Separate Delivery" DRM method and specifies "Nokia 3650" handset type, 
which implements the OMA DRM vl forward lock functionality only, the DRM 
server will return an appropriate error together with content protected according to 
OMA forward lock protection rules, thus providing "best-effort" protection. 



Reference: 

[1] ETSI TS 123 140 V5.9.0 (2003-12) 

Digital cellular telecommunications system (Phase 2+); 

Universal Mobile Telecommunication System (UMTS); 

Multimedia Messaging Service (MMS); 

Functional description; 

Stage 2 

(3 GPP TS 23.140 version 5.9.0 Release 5) 

It is appreciated that various features of the invention which are, for clarity, described 
in the contexts of separate embodiments may also be provided in combination in a 
single embodiment. Conversely, various features of the invention which are, for 
brevity, described in the context of a single embodiment may also be provided 
separately or in any suitable subcombination. 

It will be appreciated by persons skilled in the art that the present invention is not 
limited by what has been particularly shown and described hereinabove. Rather the 
scope of the invention is defined only by the claims which follow: 
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What is claimed is: 

CLAIMS 

1 . Apparatus substantially as described hereinabove. 

2. Apparatus substantially as shown in the drawings. 

3. A method substantially as described hereinabove. 

4. A method substantially as shown in the drawings. 

5. A system substantially as described hereinabove. 

6. A system substantially as shown in the drawings. 
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Scope 

This document describes the interface between the Service Provider (SP) and NDS 
Digital Rights Management (DRM) server. 



Related Documents 



Doc. Designation 



Document Title 



[1] OMA-Download 
DRMCF-v1_0- 
20031 11 3-C: 


OMA DCF file format 


[21 OMA-Download- 


OMA DRM 


DRM-V1J)- 




20031031-C: 




[3] OMA-Download- 
DRMREL-V1_0- 
20031 031 -C 


OMA DRM Rights expression language 



The OMA reference documents listed above can be found at the following URL: 
http://www.openmobilealliance.org/release program/e nabler releases.html 



Overview 



This interface defines communication between the service provider and NDS DRM 
server. The main functions of the interface are: 

• Protecting content 

• Generating a Rights Object (RO) to regulate content rendering by a Mobile 
Subscriber (mobile subscriber) 

The interface supports all types of content protection (Forward Lock, Combine 
Delivery, Separate Delivery) and full functionality of ROs defined in [3]. RO 
functionalities are triggered by a mobile subscriber request to a service provider. The 
structure of the mobile subscriber request is outside the scope of this specification. 

Additional functionalities required for the DRM server but not included in the 
interface definition below are: 

• Service provider registration/authentication 

• Mobile subscriber registration/authentication 

The SP registration is triggered by the Management Station (MGMS). The MGMS 
shell registers each SP and SP service in the DRM server. The SP registration 
protocol, as well as SP authentication, is outside the scope of this specification. 

Mobile subscriber authentication is performed by the SP upon a mobUe subscriber's 
request for content. The registration/authentication can include the mobile subscriber 
identity, e.g., MSISDN, XID, cookies as well as the handset type (e.g. Nokia 6220) 
used by mobile subscriber. 
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3.1 DRM System Component Interaction 

Figure 1 below describes how the DRM system components interact. 



Management 
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Service 

provider 

registration 




MS 



Content & RO 
request 




Content protection & 
Regeneration ^ 




Content and metadata database 



DRM database 



interface defined in this 
specification 



Figure 1 : Overview. DRM System Component Interaction 
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3,2 DRM Server's Role 

In the scope of this document, the DRM server protects content and generates the RO 
for the content consumption by the mobile subscriber. The DRM server role is to 
optimally protect content for each mobile subscriber's handset, providing each 
handset with the best security level it can accept. 

For example: if a specific handset supports the Forward Lock protection method 
only, the content for this handset should be Forward Lock-protected. If another 
handset supports both Forward Lock and Separate Delivery protection methods, the 
content for this handset should be protected by the Separate Delivery method and an 
appropriate RO should be generated and delivered to the handset as defined in 
specifications [2], [3]. 

The content protection method is chosen by the DRM server according to the 
content's handset type and MIME type. Choosing a content protection method is 
transparent to the SP. 



4. 

4.1 
4.2 
4.3 




Interface Principles 

The interface described in this document uses Simple Object Access Protocol (SOAP) 
for the messages exchange. 

Service Provider Authentication 

SP authentication is performed by the DRM server during the communication 
session with the SP. The authentication details are outside the scope of this 
document. 

Mobile Subscriber Registration/Authentication 

Mobile subscriber authentication (both Mobile Subscriber ID and Mobile Subscriber 
type) is performed by the SP. The SP is responsible for transferring the Mobile 
Subscriber ID and handset type to the DRM server. 

Permissions Handling 

The SP must provide the DRM server with all information needed for content 
protection and RO generation. One of the parameters necessary for RO generation is 
permission as defined in [3]. Permissions are the part of the business scenario 
associated with the content, e.g., how often can content be viewed. The business 
scenario defines how content can be bought by the mobile subscriber. The sequence 
for implementing permissions for a mobile subscriber is as follows: 

L The mobile subscriber selects the content. 

2. The mobile subscriber purchases rights for the content. 

3. The SP sends the permissions associated with these rights and the handset model 
name to the DRM server. 

4. The DRM server checks the handset type to determine whether permissions can 
be implemented. 

For example, if the handset supports only Forward Lock protection (Nokia 6600), 
then permissions such as "play 5 times'* cannot be implemented. If the handset is 
able to implement all permissions, the content will be optimally protected by the 
handset and an RO will be generated if needed. If the handset is not able to 
implement certain permissions, the DRM server will implement the best content 
protection available. Notification, with an error code, will be sent to the SP. 
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Optionally, an SP can request from the DRM server a list of permissions that the 
particular handset type can implement for a particular asset type. This information 
can be used by the SP to display to the mobile subscriber only the permissions that 
the handset can implement. 

4.4 Security Considerations 

The SOAP digital signature (SOAP DSIG) can be used to secure communication 
between the SP and the DRM server. 



4.5 



Real Time Asset Protection 

The DRM server supports both real time and pre-encrypted asset protection. 



Interface Structure 

The interface structure supports SOAP communication, where each transaction 
consists of request and response XML messages transferred over HTTP. 

1 . Protect content request 

a. RT-ProtectContent-reqRequest 

b. ProtectContentResponse 

2. RO request 

a. RO-reqRequest 

b. RO-Response 

3. DRM permission request 

a. DRM-permission-reqRequest 

b. DRM-permission-Response 



XML Parameter Description 

Table 1 below describes the interface parameters. 



Table 1 : Parameter Description 



Parameter Name 


Description 




This parameter defines the interface version. 


Srvld 


This parameter uniquely identifies the service in 




flip DTCA/I server 


Oil ldl y 5WJ 


RO in WBXML format 


cid 


Unique identifier generated by DRM server per 




each content encryption. Is defined in the DCF 




header 111 


MobSubsId 


Mobile subscriber ID. This complex parameter 




uniquely identifies the subscriber in the network. 


MobSubsIdType 


Sub-parameter of MobSubsId. This parameter 




defines which type of identification is used by 




the SP. 


MobSubsIdValue 


Sub-parameter of MobSubsId. This parameter 




defines the ID value used, according to the 




chosen type. 


MS model 


Mobile subscriber handset model 


TsourceContent 


This complex parameter incorporates all source 




(clear) content parameters used by the DRM 




server to protect content. 


SourceContentID 


Sub-parameter of tSourceContent. Unique ID of 




the clear content per SP This parameter is 




managed by SP and provided to DRM server as 




part of the RtProtectContentReq request. 


ContentName 


Sub-parameter of tSourceContent. This 




parameter is used in the DCF header, see [1]- 



Parameter Name 


Description 


ContentDescription 


Sub-parameter of tSourceContent. The parameter 




is optional. This parameter is used in the DCF 




header, see [1]. 


MIMELtype 


Sub-parameter of tSourceContent. This 


parameter defines the MIME type of clear 




content. 



EncodingType Sub-parameter of tSourceContent. The parameter 

is optional. When SP issues an RO request for 
super distribution of the content, the DRM server 
compares this parameter with the EncodingType 
parameter of the mobile subscriber. In case of 
encoding type incompatibility, notification will 

be sent to SP. 

ContentProviderWeb Sub-parameter of tSourceContent. The parameter 

is optional. This parameter is used in the DCF 
header see [1]. The default value of the 
parameter is configured in the DRM server 
configuration. The value from configuration is 
used if the parameter is absent from the 
RtProtectContentReq request. 

ContentVendor Sub-parameter of tSourceContent. The parameter 

is optional. This parameter is used in the DCF 
header see [1]. The default value of the 
parameter is configured in the DRM server 
configuration. The value from configuration is 
used if the parameter is absent in the 

RtProtectContentReq request. 

SourceContentLocation Sub-parameter of tSourceContent. The parameter 

is optional. This parameter defines the source 
content location. If the parameter is absent, the 
source (clear) content should be sent in the same 
HTTP stream as the RtProtectContentReq 
request. 



Parameter Name 



Description 



SourceLocation Sub-parameter of SourceContentLocation. This 

parameter defines the URL of the source content 

location, 

Sub-parameter of SourceContentLocation. The 
SourceDownloadProtocol parameter is optional. This parameter defines the 

protocol of the source content download (HTTP, 
FTP, file system). 

SourceDownloadProxy Sub-parameter of SourceContentLocation. The 

parameter is optional. The proxy is used for the 
source content download. m 

ProtectContentLocation Sub-parameter of tSourceContent. The parameter 

is optional. This parameter defines protected 
content location. If this parameter is absent, the 
protected content should be sent in the same 
HTTP stream as the RtProtectContentReqResp 
message. 

Provocation Sub-parameter of ProtectContentLocation. This 

parameter defines the URL of the protected 
content location. . 

ProtUploadProtocol Sub-parameter of ProtectContentLocation. The 

parameter is optional. This parameter defines the 
protocol of the protected content upload (HTTP, 

FTP, fde system). 

Sub-parameter of SourceContentLocation. The 
parameter is optional. The proxy is used for the 
protected content upload. 

Complex type, defines asset consumption rights. 

Sub-parameter of tAssetRights. Defines the price 
of the asset. The price is used for statistical 
purposes only. 



ProtUploadProxy 



tAssetRights 
Price 
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Parameter Name 


Description 


Currency 


ouD-parameier 01 rri.ce. me peudiiicici ia 




optional. 1 nis parameter aeiines me currency u> 




used for the price. The default value of the 




parameter is configured in the DRM server 




configuration per SP. The value from 




configuration is used if the parameter is absent. 


Price-value 


Sub-parameter of Price. The value that, along 




with currency, comprises the price. 


Permission 


Sub-parameter of tAssetKignts. ine parameter is 




optional. Permissions as defined in OMA1 (see 




r2i). 


FLflag 


Sub-parameter of tAssetRights. Forward Lock 


flag. The parameter is optional. If the parameter 




is present, the content must be protected as 




Separate Delivery with Forward Lock (see [2]). 


tmsRights 


Complex type aermes tne ngnis wmcn can oe 


implemented by the mobile subscriber for the 




specific MIME type. 


Permission 


Sub-parameter of tmsRights. Permissions as 




defined in OMA1 (see [2]). 


FLflag 


Sub-parameter of tmobile subscriberRights. 


Forward Lock flag. The parameter is optional. If 




the parameter present this means that the mobile 




subscriber of particular type supports Separate 




Delivery with Forward Lock protection type see 




121). 


DRMstatus 


Complex parameter. Defines the status of 




request execution. 


ErrorCode 


Sub-parameter of DRMstatus. 


ErrorDescr 


Sub-parameter of DRMstatus. This parameter is 




used to describe the error code. The parameter is 




optional. 
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7 I nterf ace Messages 

7. 1 Content Protection Transaction 

The request message and response message are defined in the upcoming sections. 
7.1.1 RT Protect Content Request Message 

7.1.1.1 Message definition 

<messagename= ,, RtProtectContentReqRequest"> 
<part name="Version" Iype="xsd:string7> 
<part name="srvkT type="xsd:string7> 
<part name="Source" type="nmdrm:tSourceContent7> 
<part name= ,, MobSubsId M type="nmdrm:tMobSubsId'7> 
<part name="mobile subscribermodel" type= H xsd:string n /> 
<part name="AssetRights M type="nmdrm:tAssetRights ,, /> 
</message> 
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7.1.1.2 Types used 

nomnlexTvoe tSourceContent 


diagram 




— ^SourceContentID j 

— ~ ContentName j 
— J = MimeType | 


(tSourceContent EjJ— (— — jp- 


-^"ContentProuideiWeb | 

^ContentVendor | 
r« rcontentDescription | 

SourceContentLocation |+) 
---! ProtectContentLocation E3 


namespace 


http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd 


children 


SourceContentID ContentName MimeTvoe EncodinqTvoe ContentProviderWeb 


ContentVendor ContentDescriotion SourceContentLocation ProtectContentLocation 




used by 


element 

tSourceContent 


source 


<xsd:complexType name="tSourceContent"> 
<xsd:sequence> 
<xsd:element name="SourceContentlD" type="xsd:long7> 
<xsd:element name^'ContentName" type="xsd:string7> 
<xsd:element name=="MimeType" type="xsd:string7> 

<xsd:element name="EncodingType n type^'xsdistring" ni!Iable= ,, true ,, minOccurs="0"/> 
<xsd:element name="ContentProviderWeb" type="xsd:string" niilable= n true" minOccurs="07> 
<xsd:element name= tt ContentVendor" type="xsd:string n ni!lable="true" minOccurs^O"^ 
<xsd:element name= M ContentDescription" type="xsd:string" ni!lable="true" minOccurs= w 07> 
<xsd:element name="SourceContentLocation" type="nmdrm:tSourceContentLocation" 

nillable^rue" minOccurs="07> 

<xsd:e!ement name="ProtectContentLocation" type="nmdrm:tProtectContentLocation" 

nilfable^'true" minOccurs="07> 
</xsd:sequence> 

</xsd:comp!exType> 



complexType tSourceContentLocatlon 



diagram 



[tSourceContentLocation E- j 



namespace 



children 




SourceLocation 



^"SourceDownloadProtocol 



http://www.ndsxom/NDSDRMS/vl .Q/nmdrm.xsd 



SourceLocation SourceDownloadProtocol SourceDownloadProxv 



used by 



tSourceContent/SourceContentLocation tSourceCon tentLocation 



elements 



source 



<xsd:complexType name="tSourceContentLocation"> 
<xsd:sequence> 
<xsd:element name="SourceLocation" type="xsd:string7> 
<xsd:element name="SourceDownloadProtocor type="xsd:string" nHlable= ,, true" 

minOccurs="07> m , , tfi 

<xsd:element name="SourceDownloadProxy" type=*"xsd:string" nillable= true 

minOccurs= ,, 07> 
</xsd:sequence> 

</xsd:comp!exType> 
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complexTypetProtectContentLocation 



diagram 



namespace 



children 



used by 



(tProtectContentLocatSon 




ProtLocation 



•TProtUpIoadProtocol 

• m ^ mm — m 

L-J-protUpIoadProxy | 



http://www.ndsxorn/NDSDRMS/ vl.O/nnidrm.xsd 



ProtLocation ProtUoloadProtocol ProtUplo adProxv 



elements 



tSourceContent/ProtectContentLocation tProtectConte ntLocation 



source 



<xsd:comp!exType name="tProtectContentLocation"> 
<xsd:sequence> 
<xsd:element name="ProtLocation" type="xsd:string7> 

<xsd:element name="ProtUploadProtocol" type="xsd:string" nillable="true" minOccurs= 0 /> 
<xsd:e!ement name="ProtUploadProxy" type= n xsd:string" nillable="true" minOccurs= M 07> 
</xsd:sequence> 

</xsd:complexType> 



diagram 


1 — |~MobSubsldType [I 

Ss55a — =* N s= s ^ L-=MobSubsld Value | 


namespace 


http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd 


children 


MobSubsldTvoe MobSubsIdValue 


used by 


tMobSubsid 


element 








source 


<xsd:complexType name-'tMobSubsId'^ 
<xsd:sequence> 
<xsd:e!ement name= M MobSubsldType" type="xsd:string /> 
<xsd:element name="MobSubsldValue" type="xsd:string7> 
</xsd:sequence> 
</xsd:complexType> 
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complexType tAssetRights 



diagram 


■ — Price [*] 
(tAssetRights S-T^— lEH--'! Permission Efcl 


namespace 


http://www.ndsxom/NDSDRMS/vl .0/nmdrm.xsd 


children 


Price Permission FLflag 


used by 


element 

tAssetRiqhts 


source 


<xsd:complexType name="tAssetRights"> 
<xsd:sequence> 
<xsd:eiernent name^'Price" type="nmdrm:tPrice"/> 

<xsd:element name="Permission" type^nmdrmitPermission" niilable= n true" minOccurs="0"/> 
<xsd:element name="FLflag n type="xsd:unsignedByte" nillable^'true" minOccurs= n 07> 
</xsd:sequence> 
</xsd:comp!exType> 


comolexTvoe tPrice 


diagram 


r--|~currency 3 
* L^pnceVaiue [j 


namespace 


httD://www.ndsxom/NDSDRMS/vl .0/nmdrm.xsd 


children 


currency priceValue 


used by 


elements 

tAssetRiahts/Price tPrice 


source 


<xsd:complexType name- 'tPrice'^ 
<xsd:sequence> 

<xsd:element name= M currency" type="xsd:string" nillable^'true" mlnOccurs="07> 
<xsd:element name^priceValue" type="xsd:float7> 
</xsd:sequence> 
</xsd:complexType> 
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complexType tf 
diagram 


>ermission . 

r A play S 

1 

\-i display EO 

[{Permission Eg^'^JEH, 

!aaS5sa ^ g ^ J execute [4] 

print [+] 


namespace 


httD://www.nds.com/NDSDRMS/v1.0/nmdrm.xsd 


children 


olav disolav execute print 


used by 


eiernenis 

tAssetRiahts/Permission tHS-Riqhts/Permission tPermission 






source 


<xsd:complexType name="tPermission"> 
<xsd:sequence> 

<xsd:eiement name^'play" type^nrndnTirtPerniissionElement" nillable^'true" minOccurs^O 11 ^ 
<xsd:element name="display" type= n nmdrm:tPermissionElement" nillable^true" 
minOccurs="07> 

<xsd:element name="execute" type= n nmdrm:tPermissionE!ement n niilable="true n 
m i nOccurs^'O 1 Y> 

<xsd:element name= t, print ,, type^nmdrmrtPermissionEIement" nillable^true" minOccurs= n 07> 
</xsd:sequence> 
</xsd:comp!exType> 


comolexTvoe tPermissionEIement — . , 


diagram 


(tPermissiQn£iemen^^^-^^)3— | constraint^ 


namespace 


htto://www.nds.com/NDSDRMS/v1.0/nmdrm.xsd 


children 


constraint 


used by 


elements 

tPermission/disDlav tPermission/execute tPermission/olav tPermission/Drint 




tPermissionEIement 






source 


<xsd:complexType name- tPermissionElement"> 
<xsd:sequence> 
<xsd:element name= M constraint" type= n nmdrm:constraintType7> 

</xsd:sequence> 
</xsd:comp!exType> 
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comDiexTvoe constraintType 


diagram 


r--T count 8 

(constraintType ^^^-^ "\ " j^^g^J^ 

L -4 = internal £1 


namespace 


htto://\«ww,nds.com/NDSDRMS/vl.O/nmdrm.xsd 


children 


count datetime interval 


used by 


element 

tPermissionElement/constraint constraintTvpe 




source 


<*vcH*^/\mnbvTvnp name*= , Yu3nstraintT\/De">' 

<xsd:sequence> M ^ MJ 
<xsd:element name= count type— xscuni nuiauie— uue iiihiwuuu>& w# 
<xsd:element name= ,, datetime M type="nmdrm:tdatatime n minOccurs="07> 
<xsd:element name="interval M type= M xsd:int" nillable="true" minOccurs="07> 

</xsd:sequence> 
</xsd:complexType> 


complexTypet 


datatime . — 


diagram 


r-T" start 3 


namespace 


http://www.nds.eom/NDSDRMS/v1.0/nmdrm.xsd 


children 


start end 


used by 


eiemen 

constraintTvoe/datetime tdatatime 


source 


<xsd:complexType name-'tdatatime'^ 
| <xsd:sequence> . 

<xsd-element name^start" type^xsdidateTime" nillable="true M mmOccurs= 0 /> 
<xsd:element name= M end" type="xsd:dateTime" nillable^true" minOccurs="07> 
</xsd:sequence> 
</xsd:comp!exType> 
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7.1.1.3 XML example 

<?xml versioiWl.O" encoding= ,, UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV= n http://schemas.xmlsoap.org/soap/envelope/ M 
xmlns:SOAP-ENC== ,, http://schemas.xmlsoap.org/soap/encoding/ ,, 

xmlns:xsi="http://www.w3.^^ 
xmlns:xsd« ,, http://vmw.w3.org/2001/XMLSchema" 

xmlns:nmdrm= M http://ww^ 

<SOAP-ENV:Body id="_O n SOAP- 
ENV:encodingStyle="http://schem^ 

<nmdrm:RtProtectContentReq> 

<Version/> 

<srvId/> 

<Source> 

<SourceContentID>230965</SourceContentID> 
<ContentNanie "Bond" /> 
<MimeType "application/jpg" /> 
<ContentDescription "nice jpg picture"/> 
<SourceContentLocation> 

<SourceLocation n http://mobile.nds.com/clearcontent7> 
<SourceDownloadProxy/> 
</SourceContentLocation> 
► <ProtectContentLocation> 

<ProtLocation "http://mobile.nds.com/protectcontent7> 
i <ProtUploadProxy/> 
</ProtectContentLocation> 
</Souxce> 
<MobSubsId> 

<MobSubsIdType "mobile subscriberISDN7> 
<MobSubsIdValue "97255664541 7> 
</MobSubsId> 



<mobile subscribermodel "1^0^6220" /> 
<AssetRights> 
<Price> 

<priceValue>5.5</priceValue> 
</Price> 
<Permission> 
<play> 

<cons train t> 

<count>3</count> 

</play> 
</Permission> 
<FLflag>0</FLflag> 
</AssetRights> 
</nmdrm:RtProtectContentReq> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

7.1 .2 RT Protect Content Response Message 
7,1.2.1 Message definition 

<message name=TrotectContentReqResponse"> 

<part name="DRMstatus" type= ,, nmdrm:tDRMstatus7> 
<part name="Cn)" type="xsd:string7> 
</message> 



7.1.2.2 Types used 



complexType tDRMstatus 



diagram 


(tDRMstatus g 




| — ErrorCode j| 
---J 3 ErrorDescr | 


namespace 


htto://www.ndsxom/NDSDRMS/vl.O/nmdrm.^ 


children 


ErrorCode ErrorDescr 


used by 


elements 

ProtectContentReaResoonse/DRMstatus RoReaResoonse/DRMstatus 


DrmPermissionReaResDonse/DRMstatus tDRMstatus 




source 


<xsd:complexType name^'tDRMstatus 1 ^ 
<xsd:sequence> 
<xsd:e!ement name^'ErrorCode" type= M xsd:int'7> 

<xsd:element name="ErrorDescr" type="xsd -.string" nillabie^true" minOccurs="07> 
</xsd:sequence> 
</xsd : com pi exType> 
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7.1.2.2.1 XML example 

<?xml version= n 1.0" encoding= ,, UTF-8 , '?> 

<SOAP-ENV:Envelopexnilns:SOAP-ENV^ 
xmlns:SOAP-ENC="http://schemas.x^llsoap.o^g/soap/encoding/ ,, 

xmlns:xsi="http://www.w3.^^ 
xmlns:xsd= ,, http://www.w3.org/2001/XMLSchema tt 

xmlns:nmdrm="http://www 

<SOAP-ENV:Body id^JT SOAP- 
EN V:encodingStyle= M http://scte ( 

<nmdrm:ProtectContentReqResponse> 

<DRMstatus> 

<EnrorCode>0</ErrorCode> 

</DRMstatus> 

<CID "Bondnnnn@mobile.nds.com" /> 
</nmdrm:ProtectContentReqResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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7.2 RO Transaction 

7.2.1 RO Request Message 

7.2.1 .1 Message definition 

<message nanie="RoReqRequest"> 

<part name="Version" type="xsd:string7> 
<part name="srvld" type="xsd:string7> 
<partname="CID" type="xsd:string7> 
<part name^'MobSubsId" type="nmdrm:tMobSubsId7> 
<part name="mobile subscriber-model" type="xsd:string7> 
<part name="AssetRights" type="nmdrm:tAssetRights7> 
</message> 

7.2.1.2 Types used 

The same types as for RT Protect Content request are used 

7.2.1.3 XML example 

<?xml version= ,, 1.0" encoding= ,, UTF-8"?> 

<SOAP-ENV:EnveIope xmlns:SOAP-ENV= n http://schemas.xmlsoap.o^g/soap/envelope/ ,, 

xmlns:SOAP-ENC= ,, http://schemas.xmlsoap.org/soap/encoding/" 

xmIns:xsi="http://wvw.w3.org/2001/XMI^chema-instance" 

xmlns:xsd= n http://www.w3.org/2001/XMLSchema n 

xmlns:nmdrm="http://www.ndsxorn^ 

<SOAP-ENV:Body id="_0" SO AP- 
ENV:encodingStyle= ,, http://schemas.xmlsoap.org/soap/encoding/ ,, > 

<nmdrm:RoReq> 

<Version tt 1.0"/> 

<srvId"NDS01247> 

<C1D "Bondnnnn@mobile.nds.com" /> 

<MobSubsId> 

<MobSubsIdType "mobile subscriberISDN"/> 



<MobSubsIdValue "97255664541 7> 
</MobSubsId> 

<mobile subscribermodel "Nokia6220 rt /> 

<AssetRights> 

<Price> 

<priceValue>7.5</priceValue> 

</Price> 
<Permission> 
<play> 

<constraint> 

<count>5</count> 

</play> 
</Permission> 
<FLflag>0</FLflag> 
</AssetRights> 
</nmdrm:RoReq> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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7.2.2 RO Response Message 

7.2.2. 1 Message definition 

<message nanie="RoReqResponse"> 

<part name^'DRMstatus" type= M nmdrm:tDRMstatus7> 

<part name^'RightsObject" type= n xsd:hexBinary7> 
</message> 

7.2.2.2 Types used 

The same type as for RT Protect Content response is used. 

If ErrorCode parameter in the DRMstatus does not equal M OK", the RightsObject 
parameter in the response message is absent. 

7.2.2.3 XML example 

<?xml versknWl.O" encoding="UTF-8"?> 

<SOAP-ENV:Envelopexmins:SOAP-ENV= ,, http://schenlas.xmlsoap»o^g/soap/envelope/ ,, 

xmlns:SOAP-ENC= ,, http://schemas.xmlsoap.org/soap/encoding/" 

xmlns:xsi= ,, http://www.w3.org/2001/XMLSchema-*instance M 

xmlns:xsd= n http://www.w3.org/2001/XMLSchema ,, 

xmlns:nmdrm=="http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd ,, > 

<SOAP-ENV:Body id=J) n SOAP- 
ENV:encodingStyle="http://schemas.xrnisoap.org/soap/encoding/"> 

<nmdrm:RoReqResponse> 
<DRMstatus> 

<ErrorCode>0</EiTorCode> 

<ErrorDescr/> 
</DRMstatus> 
<RightsObject> 

<ptr>0</ptr> 

<size>0</size> 
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</RightsObject> 
</nmdrm:RoReqResponse> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 



7.3 



DRM Permission Transaction 



7.3.1 



DRM Permission Request Message 



7.3.1.1 



Message definition 



<message name= M DrmPermissionReqRequest"> 

<part name^'Version" type= H xsd:string7> 

<part name^'srvld" type="xsd:string7> 

<part name= H mobile subscribermoder type="xsd:string7> 

<part name^MimeType" type="xsd:string7> 

</message> 



<?xml version="1.0" encoding="UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-EKV= u http://schemas.xnUsoap.org/soap/env 

xJrnIns:SOAP-ENC= n http://schemas.xmlsoap.o^g/soap/encoding/ ,, 

xnilns:xsi=Tittp://ww.w3.or^^ 

xmlns:xsd="http://www. w3.org/2001/XMLSchema" 

xmlns:nmdrm="http://www.ndsxom/NDSDmS 

<SOAP-ENV:Body id= M J> tt SOAP- 
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/ ,, > 

<rundrm:DrmPermissionReq> 

<Version> 1.0 </Version> 

<srv!d>NDS2300 </srv!d> 



7.3.1.2 



Types used 

The same types as in RT request message are used. 



7.3.1.3 



XML example 
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<mobile subscribermodel> Nokia6220 </mobile subscribermodel> 
<MimeType> application/jpg </MimeType> 
</nmdrm:DrmPermissionReq> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 



7.3.2 DRM Permission Response Message 



73.2.1 Message definition 

<message name= ,, DrmPermissionReqResponse ,, > 

<part name= ,, DRMstatus" type="nmdrm:tDRMstatus7> 

<part name= ,, mobile subscriberRights" type="nmdrm:tmobile subscriberRights7> 
</message> 
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7.3.2.2 Types used 



comptexType tmobile subscriberRights 



diagram 


- - -j permission [+] 

(tMsrogtits ^H^)3--i 


namespace 


httn://www.nds.com/NDSDRMS/v 1 .0/nmdrm.xsd 


children 


Permission FLflaq 


used by 


elements 

DrmPermissionReaResDonse/mobile subscriberRights tmobile subscriberRiahts 






source 


<xsd:complexType name="tmobile subscriberRights"> 
<xsd:sequence> 

<xsd:element name= n Permission M type^'nmdrmitPermission" niliable="true" minOccurs="0 , 7> 
<xsd:element name=TLfIag" type="xsd:unsignedByte" niliable="true" minOccurs="07> 
</xsd:sequence> 
</xsd:complexType> 



The other types are the same as in the RT Response message. 



7.3.2.3 XML example 

<?xml version="1.0" encoding= ,, UTF-8"?> 

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/ M 

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/ ,, 

xmlns:xsi="http://www.w3.or^^ 

xmlns:xsd="http://www.w3.org/2001/XMLSchema" 

xmlns:mndrm= ,, http://vsww.n^ 

<SOAP-ENV:Bodyid=" JT SOAP- 
ENV:encodingStyle= ,, http://schemas.xmlsoap.org/soap/encoding/"> 

<nmdrm:DRM-permission-Response> 

<DRM-status> 

<ErrorCode>0</EiTorCode> 

<ErrorDescr/> 



</DRM-status> 



<mobile subscriberRights> 
<Permission> 
<play> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 
<interval>0</interval> 
</constraint> 
</play> 
<display> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 
<interval>0</interval> 
</constraint> 
</display> 
<execute> 

<constraint> 

<count>0</count> 
<datetLme> 
<start/> 
<end/> 
</datetime> 



<interval>0</interval> 
</constraint> 
</execute> 
<print> 

<constraint> 

<count>0</count> 
<datetime> 
<start/> 
<end/> 
</datetime> 
<interval>0</interval> 
</constraint> 
</print> 
</Permission> 
<FL-flag>0</FL-flag> 
</mobile subscriberRights> 
</nmdrm:DRM-pennission-Response> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 
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8 Error Handling 



Table 2 below describes the errors that the SP may receive in response to a request. 
Table 2: Error Handling 



Error code 


Error description 


0x0000 


Successful execution of the request 


0x0001 


Mobile Subscriber type is not defined in the DRM server 


0x0002 


Clear content file cannot be found 


0x0003 


Protected content location does not exist 


0x0004 


Download protocol is not supported 


0x0005 


Upload protocol is not supported 
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Appendix A: WSDL Schema of Protocol 

<?xml version="1.0" encoding="UTF-8 n ?> 

definitions name^'NDSdntiPortal" xiTllns= ,, http://scheITlas.xmlsoap.org/wsdl/ ,, 

x^nlns:SOAP= ,, http://schemas.xnllsoap.o^g/wscil/soap/ ,, 

xmlns:WSDL="http://schenias.xmlsoap.org/wsdl/ M 

tarratNamespac^ 

» xin l ns: tiis="http://www.ndsxom^DSDRMS/NDSdrmPort^ 

xmlns:SOAP-ENV« ,, http://schemas.x^llsoap.org/soap/envelope/ ,, xmlns:SOAP- 

ENC= ,, http://schemas.xmlsoap.org/soap/encoding/ l, 

xmlns:xsi="http://www.w3.o^g/2001/XMl^chema-instance ,, 

xmlns:xsd="http://wvsw.w3.org/2001/XMLSchema H 

xmlns:nmdrm= ,, http://www.ndsxommDSDRMS/vl.O/nmdrm 

<types> 

<schematargetNamespace= ,, http://www,nds.com/NDS 
xmlns:SOAP-ENV= M http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- 
ENC= ,, http://schemas.xmlsoap.o^g/soap/encoding/ ,, 
xmlns:x5i= t, http://www. w3.org/2001/XMLSchema-instance" 
xmlns:xsd= ,, http://www.w3.org/2001/XMLSchema ,, 
xmlns:mndrm= w ht±p://www.ndsxom/NDSDm 

xmlns="http://wMW.w3.org/2001/XMLSchema ,t elementForm Default^' unqualified" 
attributeFormDefault= ,, unqualified"> 

<element name="tProtectContentLocation" 
type= ,, nmdrm:tProtectContentLocation7> 

<complexType name="tProtectContentLocation"> 
<sequence> 

<element name="ProtLocation" type^'^distring" minOccurs-'T' 

maxOccurs="l7> 

<element name= ,, ProtUploadProtocol" type-'^d^tring" 
minOccurs= ,, 0 ,, maxOccurs^l" niliable="true7> 

<element name="ProtUploadProxy" type^^stiing" minOccurs="0 M 
maxOccurs^'r* nillable="true7> 
</sequence> 
</complexType> 

<element^ame="tSourceContentLocation ,, 
type="nmdrm:tSouxceContentLocation"/> 
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<comp!exType name="tSourceContentLocation M > 
<sequence> 

<element name= n SourceLocation" type^xsdzstring" minOccurs= n l n 

maxOccurs="l7> 

<element name= ^ Sou^ceDownloadP^otoco^ , type= ,, xsd:string" 
minOccurs="0" maxOccurs="l n nillable= n true7> 

<element name= tt SourceDownloadProxy" type=°xsd:string" 
HiinQccurs^O" maxOcciirs= ,, l" nmable= H true7> 
</sequence> 
</complexType> 

<element name= M tSourceContent" type="nmdrm:tSourceContent7> 
<complexType name= M tSourceContent"> 
<sequence> 

<element nanie= 'SourceContentlD'* type="xsd:long" minOccurs='T' 

maxOccurs="l7> 

<element name="ContentName M type^'xsdrstring" minOccurs= ,, l" 

maxOccurs="l7> 

<elementname="MimeType ,, type="xsd:string" minOccurs= ,, l M 

maxOccurs=" 1 7> 

<element name^'EncodingType" type^^stiing' 1 minOccurs= tt 0" 
maxOccurs="l" nillable= ,, true7> 

<element name= ,, ContentProviderWeb M type="xsd:string" 
minOccurs= ,, 0" maxOccurs= M r nfflable="true7> 

<elementname= ,, ContentVendor" type^xsdrstring" minOccurs="(T 
maxOccurs^T nillable= M true7> 

<element name= "ContentDescription'' type^xsdtstring" 
minOccurs="0 tt maxOccurs= M l" ni]]able="true7> 

<element name= n SourceContentLocation" 
type= M nmd^m:tSou^ceContentLocation ,, minOccurs="0" maxOccurs^T nillable= n true7> 

<element nanie= ProtectContentLocation" 
type^^nmdrmitProtectContentLocation" minOccurs="0" maxOccurs="l" nillable= n true7> 

</sequence> 
</complexType> 
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<element name="tMobSubsId" type=''nmdrm:tMobSubsId7> 
<complexType name="tMobSubsId ,, > 
<sequence> 

<element nanie="MobSubsIdType" type='*xsd:string" minOccurs=°l" 

maxOccurs= ,, r , /> 

<element name="MobSubsIdValue" type="xsd:string" minOccurs^l" 

maxOccurs='T7> 

</sequence> 
</compIexType> 

<element name^tdatatime" type= M nmdrm:tdatatime7> 
<complexType name="tdatatime n > 
<sequence> 

<elementname= ,, start n type="xsd:dateTime" minOccurs="0" 
maxOccurs-'l" nillable= M true7> 

<element name="end" type='xsd:dateTime" minOccurs="0" 
maxOccurs="l" nillabie="trae7> 
</sequence> 
</complexType> 

<element name="constraintType" type^-nmdrmxonstraintType"^ 
<complexType name= n constraintType"> 
<sequence> 

<element name= w count B type="xsd:int u minOccurs="(r 
maxOccurs="l n nillable="true7> 

<element name= tt datetime 0 type="nmdrm:tdatatime r, minOccurs^O" 
maxOccurs^T' njilable= n true7> 

<element name="interval" type="xsd:int M minOccurs^O" 
maxOccurs="l" nillable="true7> 
</sequence> 
</complexType> 

<element nanie="tPermissionElement" type= tt nmdrm:tPermissionElement7> 
<comp!exType name= n tPernussionElement"> 



<sequence> 

<element name^'constraint" type= ,, nmci^m:constraintType ,, 
minOccurs= H l" raaxOccurs="l7> 
</sequence> 
</compIexType> 

<element na^le= ,, tPe^nission l, type="nmdrm:tPermission7> 
<complexType name="tPermission"> 
<sequence> 

<element name="play tt type^'^mdrmitPermissionElement" 
minOccurs= ,, 0" maxOccuis="l n nillable= n true7> 

<element name^display" type= n nmdrm:tPermissionElement" 
minOccurs^'O" maxOccurs^T' niUable="true7> 

<element name="execute" type="nmdrm:tPermissionElement n 
minOccurs^O'* maxOccurs= , l n niilable= H true7> 

<element name="prinr type^^nmckmrtPennissionElement" 
minOccurs-"0" maxOccurs^l" niliable==:"true7> 
</sequence> 
</complexType> 

<element name^tPrice" type= ,, nmdrm:tPrice7> 
<complexType name="tPrice"> 
<sequence> 

<element name^'currency" type="xsd:string" minOccurs^'O" 
maxOccurs="l" nillable="true7> 

<element name^priceValue" type^' xsdrHoat" minOccurs= u r 

maxOccurs=" 1 ' 7> 

</sequence> 
</complexType> 

<element name="tAssetRights" type= f, nmdrin:tAssetRights7> 
<complexType name= n tAssetRights"> 
<sequence> 
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<element name="Price" type= ,, nmd^m:tPrice ,, minOccurs^T' 

maxOccurs= ,, l , 7> 

<elementname=Termission n type= t, nmdrm:tPermission n ' 
minOccurs= u O n maxOccurs= n l M nillable="true , 7> 

^lementname^FLflag" type^xsdrunsignedByte 1 ' minOccurs="0" 
maxOccurs-"!" nillable="true7> 
</sequence> 
</complexType> 

^element name="tmobile subscriberRights" type== M nmdnn:tmobile 
subscriberRights7> 

<complexType name="tmobile subscriberRights n > 

<sequence> 

<element name= n Permission" type= ,, nmdrm:tPermission" 
minOccurs= ,, 0 n maxOccurs-l" niliable= H true7> 

<elementname="FLflag" type^xsdrunsignedByte" minOcciirs= , '0" 
maxOccurs^T' nillable= w true7> 
</sequence> 
</complexType> 

<element name-"tDRMstatus° type^'nmdrmrtDRMstatus"^ 
<complexType name="tDRMstatus"> 
<sequence> 

<element name="ErrorCode M type="xsd:int" minOccurs="r 

maxOccurs="l"/> 

<element name= u ErrorDescr" type="xsd:string" minOccurs^'O" 
maxOccurs= M l" nillable="true7> 
</sequence> 
</complexType> 

<elementname="ProtectContentReqResponse" 
type= rt nmdrm:ProtectContentReqResponse7> 

<complexType name=TrotectContentReqResponse"> 

<sequence> 
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<element name="DRMstatus" type="nmdrm:tDRMstatus" 
minOccurs="l" maxOccurs='T7> 

<element name= ,, CID" lype^' xsdistring" minOccurs^T' 

maxOccurs="r/> 

</sequence> 
</complexType> 

<element name="RoReqResponse n type=' , nmdrm:RoReqResponse7> 
<complexType name^'RoReqResponse'S 
<sequence> 

<element name^'DRMstatus 1 ' type^nrndrmitDRMstatus" 
minOccurs='*r maxOccurs="17> 

<element nanie= ,, RightsObject ,t type=''xsd:hexBinary n minOccurs^l" 

maxOccurs='TV> 

</sequence> 
</complexType> 

<elementname="DrmPermissionReqResponse n 
type="nmdrm:DrmPermissionReqResponse , 7> 

<complexType name= n DrmPermissionReqResponse"> 
<sequence> 

<element name^DRMstatus" fcype="nmdrm:tDRMstatus w 
minOccurs= n r maxOccurs="l7> 

<element name='mobile subscriberRights" type="nmdrm:tmobile 
subscriberRights" minOccurs="l" maxOccurs="l7> 
</sequence> 
</complexType> 
</schema> 
</types> 

<message name="RtProtectContentReqRequest ,t > 
<partname="Version" type= tt xsd:string7> 
<part name^srvld" type="xsd:string7> 
<part name= M Source" type="nmdrm:tSourceContent7> 
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<part name=="MobSubsId M type="nmdrm:tMobSubsId7> 
<part name="mobile subscribermodel" type="xsd:string7> 
<part name=" AssetRights" ty pe= tt nmdrm:tAssetRights7> 
</message> 

<messagename="ProtectContentReqResponse"> 

<part name="DRMstatus" type="nmdrm:tDRMstatus7> 

<partname="CID" type="xsd:string7> 
</message> 

<message name="RoReqRequest"> 

<part name=" Version" type="xsd:string7> 

<part name="srvld" type= n xsd:string7> 

<part name="CID" type="xsd:string7> 

<part name="MobSubsId" type="nmdrm:tMobSubsId7> 

<part name="mobile subscribermodel" type="xsd:string7> 

<part name=" AssetRights" type== n nmdrm:tAssetRights"/> 
</message> 

<message name="RoReqResponse"> 

<part name="DRMstatus" type= ,, nmdrai:tDRMstatus , 7> 

<part name^'RightsObject" ry pe="xsd:hexBinary7> 
</message> 

<message name="DrmPermissionReqRequest n > 

<part name=" Version" type="xsd:string7> 

<part name="srvld" type="xsd:string"/> 

<part name="mobile subscribermodel n type="xsd:string"/> 

<part name="MimeType" ty pe="xsd:string7> 
</message> 

<messagename="DrrnPermissionReqResponse"> 

<part name=="DRMstatus" type="nmdrm:tDRMstatus7> 

<part name="mobile subscriberRights" type="nmdrm:tmobile subscriberRights'7> 
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</message> 

<portType name=' , NDSdrmPortalPortType ,, > 

<operation name="RtProtectContentReq"> 

<documentation>Service definition of function 
nmdrm_RtProtectContentReq</documentation> 

<input message- M tns:RtProtectContentReqRequest , 7> 
<output message="tns:ProtectContentReqResponse , 7> 
</operation> 

<operation name="RoReq"> 

<documentation>Service definition of function 
nmdrm_RoReq</documentation> 

<input message= rt tns:RoReqRequest7> 
<output message="uis:RoReqResponse7> 
</operation> 

<operation name^'DnnPerniissionReq'^ 

<documentation>Service definition of function 
nmdrm_DrmPermissionReq</documentation> 

<input niessage= ,, tns:DrmPermissionReqRequest"/> 
<output message="tns:DrmPermissionReqResponse7> 
</operation> 
</portType> 

<binding name="NDSdrmPortalBinding" type="tns:NDSdrmPortalPortType"> 

<SOAP:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http7> 
<operation najTie= ,, Ru°rotectContentReq"> 
<SOAP:operation soapAction="7> 
<input> 

<SOAP:body use="encoded w 
namespace^'http^/w^ 

encodingStyle= ,, http://schemas.xmlsoap.org/soap/encoding/"^ 
</input> 



<output> 

<SOAP:body use= M encoded" 
namespace="http://wvsrw.ndsxon^DSDRMS/vl.O/nmdrm 
encodingStyle= ,r http://schemas.xmlsoap.org/soap/encoding/7> 

</output> 
</operation> 

<operation name^'RoReq'^ 

<SOAP:operation soapAction="7> 

<input> 

<SOAP:body use="encoded" 
namespace= ,T http://www.ndsxom/NDSDImS/vl.O/nmd^m.xsd ,, 
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/7> 

</input> 

<output> 

<SOAP:body use="encoded" 
naniespace= t 'http://ww.ndsxom/NDSDmS/vl.O/nmdrm.xsd" 
encodingStyle^ ,, http://schemas.xmlsoap.org/soap/encoding/7> 

</output> 
</operation> 

<operation name= n DrmPermissionReq u > 
<SOAP:operation soapAction= n 7> 
<input> 

<SOAP:body use="encoded" 
naniespace="http://www.ndsxom/NDSDRMS/vl.O/nmdrm.xsd M 
encodingStyle= n http://schemas.xrnlsoap.org/soap/encoding/'7> 

</input> 

<output> 

<SOAP:body use="encoded" 
namespace="http://www.ndsxom/NDSDRMS/vLO/nmd^m.xsd ,, 
encodingStyle=°http://schemas.xmlsoap.org/soap/encoding/7> 

</output> 
</operation> 
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</binding> 

<service name= M NDSdrmPortal"> 

<documentation>gSOAP 2.3 rev 2 generated service definition</documentation> 
<port name= ,, NDSdrmPortal" binding="tns:NDSdrmPortalBinding"> 

<SOAP:address 
locaUon="http://www.ndsxom/NDSDRMS/NDSdrmPortal7> 

</port> 
</service> 
</definitions> 
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Technical Glossary: Acronyms and Abbreviations 



Knowledge of the acronyms and abbreviations defined in this technical glossary may 
be helpful to understanding the information in the present document. 



Acronym/Abbreviation 


DeTinicion 


DCF 


DRM Content Format 


DRM 


Digital Rights Management 


DSIG 


Digital Signature 


HS 


Handset 


ICD 


Interface Component Document 


MIME 


Multipurpose Internet Mail Extension 


MGMS 


Management Station 


MS 


Mobile Subscriber 


MSISDN 


Mobile Station Integrated Services Digital Network 


OMA 


Open Mobile Alliance organization 


RO 


Rights Object 


SP 


Service Provider 


WBXML 


WAP (Wireless Application Protocol) Binary Extended 


Markup Language 


WSDL 


Web Service Definition Language 


XID 


Exchange Identifier 
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